Check alternate chains prior to default chain when providing force_chain - #203
Check alternate chains prior to default chain when providing force_chain#203oskgu360 wants to merge 1 commit into
Conversation
This allows for retrieving the alternate chain when both default and alternate contain the provided issuer
|
Yeah, I see the issue with that. It seem to me that you could end up with the same problem but in the other direction if alternate/default were flip. I will have to think of something. What would you think if the client allowed you to pass a lambda to match it yourself? certificate(url: url, force_chain: lambda {|issuer| !issuer.include?('DST Root CA X3') }) |
|
Hmm, not seeing how it would cause issues if you flip alternate/default. As long as there's only two options the default one could always be achieved by not providing any force_chain? However if there would be more than 2 options I suppose it would become problematic. I believe your proposal would cover all cases, however using it does not feel very intuitive without knowing the underlying code. |
|
Let's Encrypt recently flipped the defaults again (https://letsencrypt.org/2023/07/10/cross-sign-expiration.html) so this is no longer needed. The |
3 participants
Let's Encrypt changed their default and alternate chains as of May 4th.
https://community.letsencrypt.org/t/production-chain-changes/150739
Issue is that we are unable to retrieve the new alternate chain as the force_chain attribute (in this case 'ISRG Root X1') is included in the default chain as well as the alternate.
This change allows for retrieving the alternate chain when both default and alternate contains the provided issuer. If one wants the default chain, then they can simply not provide any force_chain attribute.